[Previous] [Next] [Index] [Thread]

Re: Unix links subverting Web security

"David H. Brierley" <dhb@ssd.ray.com> writes about chroot:

>If someone can tell me some basic flaw in my setup I would love to hear
>it.  I have not found any way to defeat the security and nothing I have
>seen on this list so far has indicated a way to defeat the security.  I am
>currently running the NCSA server, version 1.4, with a minor mod to support
>the chroot capability.

There may not be a cracker out there today that can break today's
setup. But here are some things to consider regarding the overall
approach. These issues may be acceptable to your site's security
policy, though sites with higher security requirements find these to
be of concern:

1) As you've noted, chroot's effectiveness depends on making all the
right changes to chroot'ed applications to comply with its operating
constraints. I've noticed that people are learning reactively just
what all those constraints are, following the lead of crackers who
find new ways out of chroot. There's no reason to believe we've
identified all the restrictions that an application must comply with
to run securely under chroot. I admit, as a high assurance TCB
booster, that I'm fundamentally put off by chroot's hazy protection
semantics.

2) chroot was developed to control file system access, and this is not
the only way an errant chroot'ed process can be a security risk. You
may also want to review the potential risks of an errant process
accessing your internal network from within the chroot environment.
This may be version dependent, though.

3) chroot's behavior and effectiveness seems to depend on what version
of Unix you have.  Because of subtle differences, an application that
is correctly chroot'ed for one version of Unix may not be secure when
running under another.  The chroot bugs I've seen reported in the open
tend to be version specific (i.e. file table visibilities inside the
kernel).

4) Misbehavior by an application can invalidate chroot's protection.
This is a Bad Thing. Yes, you can read every line of source code
before you put it on your system, but that increases the engineering
overhead. Also, code review isn't an foolproof or easy process.

5) Having to depend on the application for security is also bad
because you need to replace application software with new versions
every so often. Thus, you can securely provide a given chroot'ed
service long term only if you can absorb the future engineering costs
of chroot'ing the newer versions of the applications.

But of course, it's a site policy decision that trades off between
onsite engineering costs, potential damage of an attack, and costs of
alternative protection technologies.

Rick.
smith@sctc.com       secure computing corporation